-
-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support Spectrum1D reading from file with flux in counts #1018
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1018 +/- ##
==========================================
+ Coverage 70.03% 70.13% +0.09%
==========================================
Files 64 64
Lines 4339 4346 +7
==========================================
+ Hits 3039 3048 +9
+ Misses 1300 1298 -2 ☔ View full report in Codecov by Sentry. |
You sure you didn't mean Jy? |
Are we able to turn that example you provided into a test? |
No, this is for spectral axis, not flux, so I just chose a random compatible unit for the spectral axis. Swap out with
Sure, we could provide a regression test for this same hardcoded case, but it really would only test that someone doesn't revert this commit... so I'm wondering if it makes more sense to write general tests with the longer-term solution? Happy to basically copy-paste this in to a test though just to make sure it doesn't raise errors. |
Doh! Ignore me... 😆
Right, we wouldn't want regression, which could happen if we ever refactor the internals. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the test could be written using parametrize
and there is no need for random number generator. Please see suggestions.
Not sure what's up with the change log, maybe @rosteen only updates it on release? https://github.com/astropy/specutils/blob/main/CHANGES.rst
Yeah, I've been updating it when I do a release. I'm certainly not opposed to people updating it when they make a PR though! I'm going to approve this, but generally agree with your suggestions @pllim . I'm about to log off for vacation but feel free to merge this once those are addressed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with the requested changes, otherwise this looks sensible. Yes, Spectrum1D.__init__
does not make any checks on flux PhysicalType
, but there you are directly passing your quantity. parsing_utils
are searching for some compatible data fields in an input file, so it makes sense to be more conservative.
Co-authored-by: P. L. Lim <2090236+pllim@users.noreply.github.com>
1ab55d0
to
fec6908
Compare
@dhomeier , does the PR look okay to you now, or is there something else? Thanks! |
Everything you had requested as far as I can see; good to me too, thanks! |
Thanks, all! |
this PR implements an exception to support reading a Spectrum1D from a file with fluxes in counts. This does not however address more general reading round-tripping such as the one reported in #997. Note also that this is just hardcoding an additional exception,
Spectrum1D
currently doesn't seem to do any unit checking on the inputs for flux, and so other units might result in the same error (including non-sensical units, like fluxes with units of meters).Example (that used to raise an
OSError: Could not identify column containing the flux
):